home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
ien
/
ien-161
< prev
next >
Wrap
Text File
|
1988-12-01
|
15KB
|
533 lines
A Proposal for Simple Measurement Support for Users
IEN 161
R.G.Jones
November 1980
University College London
Simple IEN
Measurement 161
Support
Contents
1. Introduction...........................................1
2. Motivation.............................................1
3. Measurements...........................................1
4. Current Measurement Support............................2
5. Proposed Support.......................................3
6. Summary................................................5
Simple IEN
Measurement 161
Support
1. Introduction
The majority of this note was originally written to
address a wider problem than measurements solely within
the ARPA catenet and the orientation of the discussion
is therefore in those terms. However, it is felt that
the proposed technique would also be appropriate for
user measurements confined to the catenet.
The intention in distributing this note is to gather
initial reactions to the proposed technique and
therefore no attempt has been made to fill in all the
details.
2. Motivation
Increasingly users will wish to evaluate
communication performance across a concatenation of
varied networks. The purpose of this note is to propose
a minimal set of easily implemented facilities which
would support measurements of network performance at
the user level, in particular at the network and
transport levels. It is based on ideas originally
circulated in an INDRA Group Working Paper [1].
Given the rapid proliferation of networks and the
corresponding increase in the variety of their type and
interconnection, it is felt that the facilities should
not be tightly bound to a particular protocol but
should be supportable across as many networks as
possible. In particular, for the purposes of examples,
the environment in which the measurements would be
performed is assumed to extend beyond the ARPA catenet
system to include, for example, VANs or PTT X25-based
networks.
The note deliberately concentrates on a subset of the
requirements for a comprehensive measurement program in
the hope of ensuring rapid implementation of this
essential subset.
3. Measurements
The performance of a packet-switched network is
typically characterized by delay as a function of
throughput and the facilities proposed are intended to
support this type of measurement. In the case of
networks with a virtual call interface, the call set-up
time is obviously an additional important parameter,
- 1 - R.G.Jones
Simple IEN
Measurement 161
Support
but this can be measured without requiring co-operation
from a remote site.
Throughput and delay measurements are most easily
undertaken by employing timestamps. This technique
requires at least the provision of an echo server at a
remote site. Useful results, such as round-trip time,
can be obtained with even the simplest echo server. If
global clock sychronization can be achieved (for
example, within a satellite-based net or by the use of
broadcast time standards) then timestamping at
intermediate points is particularly valuable in
pinpointing the origins of delay and throughput
constraints. However, the insertion of timestamps by
remote sites requires an agreed format and location
within the packet for the timestamps and an agreed
triggering mechanism. In a network with adaptive
routing, it is important that the intermediate
timestamps should have some identification of their
origin associated with them.
The minimum requirements for a measurement program
are therefore seen to be a widely available set of echo
servers with triggerable timestamping facilities. A
more thorough program of work would require, for
example, participating sites to make available traffic
generators which were remotely controllable.
4. Current Measurement Support
Within the domain of nets supporting ARPA protocols,
timestamping is an option in the internet header.
Currently, however, there is no associated
identification of the origin of the timestamp.
Furthermore, the number of timestamps is limited by the
maximum size of the internet header and this is even
more restrictive if, for example, source routing is to
be employed. In measurements beyond the ARPA catenet
the internet header may well be lost in traversing
other networks where gateways may, for example, do
protocol conversion at the transport level.
Echo servers are available at gateways for packets
utilizing the Gateway-Gateway Protocol but since such
packets are treated differently from normal traffic
these are useless for throughput tests and provide
optimistic delay measurements.
- 2 - R.G.Jones
Simple IEN
Measurement 161
Support
Other available facilities suffer from comparable
restrictions. Current support is therefore felt to be
inadequate not only in a wider context, but even within
the ARPA catenet system.
The situation with regard to other nets, for example
PTT X25-based nets, is even worse and it is unrealistic
to suppose that PTTs will be forward in providing
facilities. Users will therefore be forced to be co-
operative if they wish to pursue a measurement program
of reasonable extent.
5. Proposed Support
The basic requirement is for a mechanism which will
allow measurements to be made across very different
nets. With regard to interworking between nets based
on different protocols, it is unreasonable to expect
groups to implement protocols specific to another
network. Central to the proposed mechanism is a
standard format for the measurement data area which is
independent of the underlying network protocol. Such a
data area can be employed as the user data of the
selected protocol. Measurement data is distinguished at
the underlying protocol level from normal traffic by
the use of a reserved protocol number or port or
whatever is appropriate to the protocol.
The proposed format is outlined in Figure 1.
The type field specifies, for example, whether the
data is to be echoed, is an echo, or whether it should
simply be dropped by the receiving process.
The flag field can be used to specify whether the
station address should be inserted by each timestamping
station and to specify the categories of sites which
should timestamp. For example, for measurements made at
the ARPANET internet datagram level, the flags could
specify that intermediate gateways should timestamp as
well as the destination.
The length field is used at the transport level as a
record delimiter.
The sequence number field is simply a field in which
the originating process can insert a data area sequence
number if so desired.
The offset field points to the location at which the
next timestamp (and possibly station identification)
should be inserted. This is updated by each
timestamping station to point beyond the timestamp it
has inserted.
- 3 - R.G.Jones
Simple IEN
Measurement 161
Support
+---------------+---------------+
| type | flags |
+---------------+---------------+
| length |
+---------------+---------------+
| sequence number |
+---------------+---------------+
| offset |
+-------------------------------+
| origin of ts#1 |
| (optional) |
+-------------------------------+
| timestamp |
| number 1 |
+-------------------------------+
| |
| timestamp |
| number n |
+-------------------------------+
FIGURE 1: Format of Measurement Data Area
A sequence of timestamps (possibly with associated
station identification) then follows the offset field.
For experiments with user data of varying sizes, the
measurement data area would be followed by padding to
the appropriate length.
For throughput tests with minimal size user data it
would, of course, be possible to dispense with all
fields except for length and type and flags, with the
latter set to indicate no timestamping.
It is intended that the traffic generator would
supply a data area large enough to contain the
anticipated number of timestamps. If it were possible
for there to be a large variation in the number of
networks traversed for a given destination that might
prove difficult to initially estimate. However, a
station unable to timestamp because of lack of space
would set a flag to indicate the fact.
Station identification in measurements across nets
with an homogeneous addressing scheme (such as the ARPA
catenet) presents no problems. However, identification
in other systems rules out a standard field size. The
PTT networks, for example, specify an international
- 4 - R.G.Jones
Simple IEN
Measurement 161
Support
address of up to 14 digits and local nets will have a
variety of further schemes. The use of timestamp
identification in the most general case is therefore a
matter for further consideration. In many situations
the problem will not arise since, for example, across
PTT nets timestamps will be available only from the
destination echo server. It may be desirable to add an
additional field either for each origin or each
origin/timestamp pair to indicate length and format.
The suggested format allows servers to be exceedingly
simple with much common code between servers at
different protocol levels.
In the ARPANET environment, echo servers for such
data should be provided above the internet datagram
level and above TCP. Thus, an internet protocol number
would be reserved for measurement packets and all such
packets processed by an internet layer in a host or
gateway would be passed to an internet datagram echo
server. It should be possible to specify timestamping
in a gateway functioning as a transit gateway rather
than the packet destination. A "well-known" TCP port
would be reserved for a server for TCP tests.
For X25-based networks, at the virtual circuit level,
a protocol number could be reserved for the "protocol
field" of the call user data area (bytes 1 through 4).
In the absence of such a universally recognized
identification, substitutes can be found. For example,
on PSS "well-known" (to co-operating sites) sub-
address digits could specify the echo server in the
DTE.
6. Summary
Attention has been drawn to the inadequacies of
current measurement support for the network user. An
outline has been given of the minimum requirements for
a user measurement program and a method of meeting the
requirements has been proposed. The central mechanism
of the proposed support is a standardized format for
measurement data, which lends itself to easy
implementation above various network protocols
accessible by the user. This scheme means that the
measurement data is independent of the protocol level
in use and may be more easily preserved across
networks.
- 5 - R.G.Jones
Simple IEN
Measurement 161
Support
The note has deliberately defined a minimal subset of
the requirements for a comprehensive measurement
program, not least because it is felt that these
facilities could be quickly provided.
It does not attempt to provide the necessary
facilities for detailed investigation of network
behaviour, but does (quickly and easily) provide
sufficient resources for the user to be able to
identify problems for further investigation.
- 6 - R.G.Jones
Simple IEN
Measurement 161
Support
References
1. Standard Timestamping - A Proposal
R.Cole and R.G.Jones, INDRA Working Paper 860,
January 1980
- 7 - R.G.Jones
